Freedom from Interference

L6 18 Freedom From Interference Communication

Common Causes of Communication Interference

There are many causes for communication faults. These causes would be analyzed in a software safety analysis or sometimes in a technical safety analysis:

Repetition of information
Loss of information
Delay of information
Insertion of information
Masquerade or incorrect addressing of information
Incorrect sequence of information
Corruption of information

Other Mechanisms for Ensuring Freedom from Communication Interference

There are a handful of measures for avoiding communication interference. These mechanisms could be used to define software safety requirements that help avoid communication faults. Mechanisms for ensuring freedom from interference include:

Loopback of information
Acknowledgement of information
Appropriate configuration of I/O pins
Bus arbitration by priority
E2E protocol

For example, one technical safety requirement was "the validity and integrity of the data transmission for 'LDW_Torque_Request' signal shall be ensured". This technical safety requirement could be refined into a software safety requirement that the data shall be protected by an End2End mechanism.

Example specification for E2E protection protocol

The image below shows an example of an E2E protocol.

The mechanism involves adding two extra data-bytes called a CRC (Cyclical Redundancy Check) and an SQC (Sequence Counter) when transmitting data. To calculate the CRC, you run a mathematical formula on the data to be transmitted. You then attach the CRC result to the data prior to transmission. When the data is received, the mathematical formula is run on the data set again. The CRC attached to the data and the CRC calculated on the receiving end should be the same; otherwise, data data has probably been corrupted in transmission.

The SQC is just a counter that gets sent along with the data. That way the receiver can make sure that messages haven't been lost.

E2E Software Safety Requirements for the Lane Departure Warning (LDW)

In the concept about "Software Safety Requirements Lane Departure Warning", we already discussed that technical safety requirement 02 could be taken care of with an E2E protocol. Let's go into more depth about this technical requirement and the related software safety requirements. Here was the technical safety requirement:

ID	Technical Safety Requirement	ASIL	Fault Tolerant Time Interval	Allocation to Architecture	Safe State
TechnicalSafetyRequirement02	The validity and integrity of the data transmission forLDW_Torque_Request signal shall be ensured	C	50 ms	Data Transmission Integrity Check	N/A

And here as well is the software safety architecture:

You can see we've added an E2E calculation for the two signals that leave the LDW Safety component. We need to make sure there is no corruption when the 'Processed_LDW_Torque_Request' signal travels to the "Final EPS Torque Generator". The E2E Calculation component would run a calculation on the signal to be transferred and attach the calculation to the signal.

Then the "Final EPS Torque Generator" component would run the same calculation and compare the results from before and after transmission. If the results are the same, then you can assume the data remains intact.

We would use the same mechanism when the "LDW_Safety_Activation" component sends its signal to the "Final EPS Torque Generator".

So here again are the software safety requirements:

ID	Technical Safety Requirement	ASIL	Allocation Software Elements	Safe State
SoftwareSafetyRequirement02-01	Any data to be transmittedoutside of the LDW Safetycomponent (“LDW Safety”)including "LDW_Torque_Req"and “activation_status” (seeSofSafReq03-02) shall beprotected by an End2End(E2E)protection mechanism	C	E2ECalc	LDW_Torq_Req= 0 (Nm)
SoftwareSafetyRequirement02-02	The E2E protection protocolshall contain attach the controldata: alive counter (SQC) andCRC to the data to betransmitted.	C	E2ECalc	LDW_Torq_Req= 0 (Nm)